FIG. 1 is a schematic diagram of a system architecture of an Evolved Packet System (EPS) according to the related art, and as shown in FIG. 1, the EPS consists of an access network and an Evolved Packet Core (EPC), wherein, the access network can be an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and so on, and the EPC includes: a Mobility Management Entity (MME), a Serving Gateway (S-GW), a Packet Data Network Gateway (P-GW), a Home Subscriber Server (HSS), a 3rd Generation Partnership Project (3GPP) Authentication Authorization Accounting (AAA) server, a Policy and Charging Rules Function (PCRF) and other support nodes.
Wherein, the MME is responsible for works related to a control plane such as mobility management, non-access layer signaling processing and user context management and so on; the S-GW is an access node gateway device connected to the E-UTRAN, and it is responsible for forwarding data between the E-UTRAN and P-GW and for caching paging wait data; the P-GW is a border gateway between a 3rd Generation Partnership Project (3GPP) evolved packet system and a Packet Data Network (PDN), and it is responsible for accessing from a user terminal to the PDN and for forwarding data between the EPS and PDN and so on; and the PCRF is a policy and charging rules function entity and is connected to an operator Internet Protocol (IP) service network through a receiving interface Rx to acquire service information. Moreover, the PCRF is connected to gateway devices in the network through interfaces Gx/Gxa/Gxc, it takes charge of initiating an IP bearer establishment, guarantees the Quality of Service (QoS) of service data and performs charging control.
The EPS also supports a User Equipment (UE) performing accessing through other non-3GPP systems besides the E-UTRAN, wherein, the non-3GPP systems implement the access through interfaces S2a/b/c, and the P-GW serves as anchor points for the 3GPP system access and the non-3GPP system access. In the system architecture of the EPS, a non-3GPP system is divided into a trusted non-3GPP IP access network and an un-trusted non-3GPP IP access network. The trusted non-3GPP IP access network can be directly connected to the P-GW through the interface S2a; the un-trusted non-3GPP IP access network needs to be connected to the P-GW through an Evolved Packet Data Gateway (ePDG), and an interface between the ePDG and P-GW is the S2b. The S2c is an interface between the UE and P-GW, and it uses a Mobile Internet Protocol Vision (IPv6) Support for Dual Stack Hosts and Routers (DSMIPv6) protocol to provide the control and mobility management.
The EPS supports IP flow mobility. FIG. 2 is a schematic diagram of an access of the IP flow mobility in the related art, and as shown in FIG. 2, the UE is in the coverage of non-3GPP access (e.g. a Wireless Local Area Network (WLAN)) and 3GPP access (e.g. the E-UTRAN) simultaneously, and it is connected to the PDN through the same P-GW through a non-3GPP IP access network and a 3GPP IP access network. In this scenario, the UE is attached to the EPC through multiple access networks, the P-GW allocates an IP address to the UE, a PDN connection (also called as an IP-Connectivity Access Network (IP-CAN) session) exists between the UE and PDN. Since different services are applicable to be transmitted with different network, the IP flow mobility can select appropriate access network transmission services according to features of the services, and multiple access networks can share network loads, thereby avoiding network congestion. If a non-3GPP access network is the WLAN, service data flow of a Hypertext Transfer Protocol (Http) and a File Transfer Protocol (Ftp) can be sent to the UE through the WLAN, and service data flow of a Voice over IP (VoIP) can be sent to the UE through the 3GPP.
FIG. 3 is a flow diagram according to the related art, wherein a UE firstly establishes a PDN connection when accessing through a 3GPP access network and then establishes the same PDN connection through a non-3GPP access, and adopts the two accesses to use the PDN connection simultaneously. Dynamic Policy and Charging Control (PCC) is deployed in the network. In the figure, when it is performed through a trusted non-3GPP access, the UE uses a DSMIPv6 protocol, and as shown in FIG. 3, the method includes the following steps 301 to 316.
In step 301, the UE accesses an EPC through the 3GPP access network, wherein, a tunnel is established between an S-GW and P-GW through a General Packet Radio Service Tunneling Protocol (GTP) or a Proxy Mobile IPv6 (PMIPv6) protocol, and there are services which have been transmitted on the tunnel.
In step 302, the UE discovers a non-3GPP access network and decides to initiate multiple accesses. If the non-3GPP access network is trusted, the UE executes an access authentication and authorization in a trusted non-3GPP access network, and the UE executes a layer 3 attachment and obtains a local IP address (i.e. an IP address1) to serve as a Care of Address (CoA). If the non-3GPP access network is un-trusted, an Internet Protocol Security (IPSec) tunnel will be established between the UE and an ePDG, and in the tunnel establishment process, the ePDG allocates the IP address1 to the UE to serve as the CoA.
In step 303, a Bearer Binding and Event Reporting Function (BBERF) located in the trusted non-3GPP access network or ePDG sends gateway control session establishment message to a PCRF and requests for establishing a gateway control session, wherein a user identifier and the IP address1 are carried.
In step 304, the PCRF returns acknowledgement message to the BBERF.
In step 305, the UE discovers a P-GW selected during the 3GPP access through a bootstrapping process of the Mobile IPv6 (MIPv6). A security association is established between the UE and a PDN. The UE uses an Internet Key Exchange2 (IKEv2) to initiate a security association establishment. An Extensible Authentication Protocol (EAP) is used for an authentication on the IKEv2. The P-GW interacts with AAA to complete an EAP authentication. Moreover, in the process, the P-GW returns an IP Address2 allocated by the P-GW during the 3GPP access of the UE, the UE uses the IP address as a Home of Address (HoA) during the DSMIPv6 binding. At this point, the P-GW functions as a Home Agent (HA).
In step 306, the UE sends DSMIPv6 binding update message to P-GW/HA, the binding update message carries (HoA, CoA, Banding Identification (BID), Flow Identification (FID)). (HoA, CoA, BID, FID) are in a corresponding relationship.
Wherein, by the HoA taking a value of IP Address2 and the CoA taking a value of IP Address1, the binding update message indicates that a corresponding BID is a binding accessing through non-3GPP, and a certain data flow of user access service identified uniquely by the FID is bound to a connection accessing through non-3GPP.
By the HoA taking a value of IP Address2 and the CoA taking a value of IP Address2, the binding update message indicates that a corresponding BID is a binding accessing through 3GPP, and a service data flow identified by the FID is bound to a connection accessing through 3GPP.
If a flow binding is newly added, the corresponding relationship also includes Routing Filters (i.e. an IP quintuple) which are used for identifying a service data flow. A corresponding relationship is established between the FID and Routing Filters through the message, and a subsequent change of the service data flow can be represented by the FID. The UE reports a default routing rule in the message, that is, the Routing Filters are a wildcard filter.
The UE also can request for moving a Service Data Flow (SDF) transmitted through the 3GPP access to the non-3GPP access network.
In step 307, after receiving the binding update message, the P-GW/HA executes multi-registry flow binding according to parameters such as the HoA, CoA, BID, FID and Routing Filters carried in the message. That is, the P-GW maintains the GTP/PMIPv6 tunnels between the P-GW and S-GW and the DSMIPv6 tunnel between the P-GW and UE, and binds the service data flow to the 3GPP access or non-3GPP access. A Policy and Charging Enforcement Function (PCEF) located in the P-GW sends an Indication of IP-CAN session modification request to the PCRF, and the PCEF will send event trigger ROUTING_RULE_CHANGE and IP flow mobility routing rule information to the PCRF (with regard to the situation of newly adding and/or moving an IP flow in the flow, the IP flow mobility routing rule information is installing and/or modifying an IP flow mobility routing rule, the IP flow mobility routing rule is a corresponding relationship between the service data flow and the access, it is identified through a corresponding relationship between the Routing Filters and a Routing Address, when the Routing Address takes a value of IP Address1, it is indicated that it is accessed through non-3GPP, and when Routing Address takes a value of IP Address2, it is indicated that it is accessed through 3GPP). The message includes a default IP flow mobility routing rule, that is, the Routing Filters are a wildcard.
If the UE moves a certain service data flow from the 3GPP access to the non-3GPP access, the PCEF will provide an IP flow mobility routing rule corresponding to the service data flow to the PCRF, so as to inform the PCRF of the mobility which occurs in a route of the service data flow. In the routing rule, the Routing Filters are an IP quintuple of the service data flow, and the Routing Address takes a value of IP Address1.
In step 308, the PCRF installs and/or modifies the IP flow mobility routing rule. If the mobility (i.e. a mobility from the 3GPP access to the non-3GPP access) occurs in the service data flow corresponding to the IP flow mobility routing rule, the PCRF updates a PCC rule correspondingly and returns the updated PCC rule to the PCEF. With regard to an IP flow mobility routing rule newly installed by the PCRF, it may cause the service data flow corresponding to the IP flow mobility routing rule to move from a default route to a route designated by the IP flow mobility routing rule. With regard to an IP flow mobility routing rule changed by the PCRF, it may cause the service data flow corresponding to the IP flow mobility routing rule to move from a source routing path to a new routing path. In the flow, the PCC rule of the transmitted service data flow which moves from the 3GPP access to the non-3GPP access is updated and then returned to the PCEF.
In step 309, the P-GW/HA returns binding acknowledgement message to the UE, the message carries the HoA, CoA, BID and FID to acknowledge that the multi-registration flow binding of the UE is successful or the multi-registration flow binding and IP flow mobility are successful.
In step 310, if a certain service data flow moves from the 3GPP access to the non-3GPP access, the PCRF will make a QoS rule according to an updated PCC rule of the service data flow and provide the QoS rule to the BBERF in the trusted non-3GPP access network or ePDG.
In step 311, the non-3GPP access network executes a specific procedure to perform a resource allocation or modification.
In step 312, the BBERF returns acknowledgement message to the PCRF.
In step 313, if a certain service data flow moves from the 3GPP access to the non-3GPP access, and if the PMIPv6 tunnel is established between the S-GW and P-GW, the PCRF will delete the QoS rule corresponding to the service data flow. The PCRF provides a QoS rule required to be deleted to a BBERF in the S-GW through the gateway control session established during the UE accessing the 3GPP access network.
In step 314, the BBERF in the S-GW deletes the QoS rule, executes a 3GPP bearer modification procedure or a 3GPP bearer release procedure, and releases resources of a service data flow moved away.
In step 315, the BBERF returns acknowledgement message to the PCRF.
If a GTP tunnel is established between the S-GW and P-GW, the P-GW will initiate the 3GPP bearer modification procedure or the 3GPP bearer release procedure after the step 308 and release resources of the service data flow moved away. The steps 313-315 will not be executed.
In step 316, the UE completes the multi-registration flow binding and the possible flow mobility, the DSMIPv6 tunnel exists between the UE and P-GW/HA, and the GTP/PMIPv6 tunnels exist between the S-GW and P-GW. The UE or the network can decide an access through which service data are transmitted according to the policy.
FIG. 4 is a flow diagram according to the related art, wherein a UE firstly establishes a PDN connection when accessing through a non-3GPP access network and then establishes the same PDN connection through a 3GPP access, and adopts the two accesses to use the PDN connection simultaneously. Dynamic PCC is deployed in the network. In the figure, the UE uses a DSMIPv6 protocol during a trusted non-3GPP access, and as shown in FIG. 4, the method includes the following steps 401 to 413.
In step 401, the UE uses the DSMIPv6 protocol to access an EPC through the non-3GPP access network, wherein, a DSMIPv6 tunnel is established between the UE and P-GW/HA, and there are services which have been transmitted on the tunnel, wherein an address allocated by the non-3GPP access network to the UE is an IP Address1 serving as a CoA, and an IP address allocated by the P-GW to the UE is an IP Address2 serving as a HoA.
In step 402, the UE discovers a 3GPP access network and decides to initiate multiple accesses. The UE establishes a PDN connection to the same PDN through a 3GPP attachment flow, and in the establishment process, the IP address allocated by the P-GW to the UE is the IP Address2, so as to guarantee that the same PDN connection is established through different accesses.
In step 403, the UE sends DSMIPv6 binding update message to the P-GW/HA, the binding update message carries (HoA, CoA, BID, FID). (HoA, CoA, BID, FID) are in a corresponding relationship. By the HoA taking a value of IP Address2 and the CoA taking a value of IP Address1, the message indicates that a corresponding BID is a binding accessing through non-3GPP, and a certain data flow of user access service identified uniquely by the FID is bound to a connection accessing through non-3GPP. By the HoA taking a value of IP Address2 and the CoA taking a value of IP Address2, the message indicates that a corresponding BID is a binding accessing through 3GPP, and a service data flow identified by the FID is bound to a connection accessing through 3GPP. If a flow binding is newly added, the corresponding relationship also includes Routing Filters. A corresponding relationship is established between the FID and Routing Filters through the message, and a subsequent change of the service data flow can be represented by the FID. The UE may report a default routing rule in the message, that is, the Routing Filters are a wildcard filter. The UE also can request for moving a Service Data Flow (SDF) transmitted through the non-3GPP access to the 3GPP access network.
In step 404, after receiving the binding update message, the P-GW/HA executes multi-registration flow binding according to the carried parameters such as the HoA, CoA, BID, FID and Routing Filters. That is, the P-GW maintains the GTP/PMIPv6 tunnels between the P-GW and S-GW and the DSMIPv6 tunnel between the P-GW and UE, and binds the service data flow to the 3GPP access or non-3GPP access. A PCEF located in the P-GW sends an indication IP-CAN session modification request to the PCRF, and the PCEF will send event trigger ROUTING_RULE_CHANGE and IP flow mobility routing rule information to the PCRF (with regard to the situation of newly adding and/or moving an IP flow in the process, the IP flow mobility routing rule information is installing and/or modifying an IP flow mobility routing rule, the IP flow mobility routing rule is a corresponding relationship between the service data flow and the access, it is identified through a corresponding relationship between the Routing Filters and a Routing Address, when the Routing Address takes a value of IP Address1, it is indicated that it is accessed through non-3GPP, and when Routing Address takes a value of IP Address2, it is indicated that it is accessed through 3GPP). The message may include a default IP flow mobility routing rule, that is, the Routing Filters are a wildcard. If the UE moves a certain service data flow from the non-3GPP access to the 3GPP access, the PCEF will provide an IP flow mobility routing rule corresponding to the service data flow to the PCRF, so as to inform the PCRF of the mobility which occurs in a route of the service data flow. In the IP flow mobility routing rule, the Routing Filters are an IP quintuple of the service data flow, and the Routing Address takes a value of IP Address2.
In step 405, the PCRF installs and/or modifies the IP flow mobility routing rule. If the mobility (i.e. a mobility from the non-3GPP access to the 3GPP access) occurs in the service data flow corresponding to the IP flow mobility routing rule, the PCRF updates a corresponding PCC rule and returns the updated PCC rule to the PCEF. With regard to an IP flow mobility routing rule newly installed by the PCRF, it may cause the service data flow corresponding to the IP flow mobility routing rule to move from a default route to a route designated by the IP flow mobility routing rule. With regard to an IP flow mobility routing rule changed by the PCRF, it may cause the service data flow corresponding to the IP flow mobility routing rule to move from a source routing path to a new routing path. In the flow, the PCC rule of the service data flow which moves from the non-3GPP access to the 3GPP access is updated and then returned to the PCEF.
In step 406, the P-GW/HA returns binding acknowledgement message to the UE, the message carries the HoA, CoA, BID and FID to acknowledge that the multi-registration flow binding of the UE is successful or the multi-registration flow binding and IP flow mobility are successful.
In step 407, if a certain service data flow moves from the non-3GPP access to the 3GPP access, and if the PMIPv6 tunnel is established between the S-GW and P-GW, the PCRF will make a QoS rule according to an updated PCC rule of the service data flow and provide the QoS rule to a BBERF in the S-GW.
In step 408, the BBERF installs the QoS rule, and the S-GW initiates and executes a 3GPP bearer modification procedure or a 3GPP bearer establishment procedure to perform a resource allocation or modification.
In step 409, the BBERF returns acknowledgement message to the PCRF.
If the GTP tunnel is established between the S-GW and P-GW, the P-GW will initiate the 3GPP bearer modification procedure or the 3GPP bearer establishment procedure after the step 405 and allocate resources of a service data flow moved in. The steps 407-409 will not be executed.
In step 410, if a certain service data flow moves from the non-3GPP access to the 3GPP access, the PCRF will delete the QoS rule corresponding to the service data flow in the non-3GPP access network or ePDG. The PCRF provides a QoS rule required to be deleted to a BBERF in the non-3GPP access network or ePDG through a gateway control session established during the UE accessing the non-3GPP access network.
In step 411, the BBERF deletes the QoS rule, initiates and executes a specific non-3GPP resource modification procedure or a specific non-3GPP resource release procedure.
In step 412, the BBERF returns acknowledgement message to the PCRF.
In step 413, the UE completes the multi-registration flow binding and the flow mobility, the DSMIPv6 tunnel exists between the UE and P-GW/HA, and the GTP/PMIPv6 tunnels exist between the S-GW and P-GW. The UE or the network can decide an access through which service data are transmitted according to the policy.
FIG. 5 is a flow diagram according to the related art, wherein a UE performs data flow mobility between two access networks after implementing the multi-registry flow binding through the flow of FIG. 3 or FIG. 4. Dynamic PCC is deployed in the network. As shown in FIG. 5, the method includes the following steps 501 to 511.
In step 501, the UE is connected to a 3GPP access or a non-3GPP access simultaneously through the flow of FIG. 3 or FIG. 4 and performs multi-registration flow binding.
In step 502, the UE sends DSMIPv6 binding update message to P-GW/HA, and the binding update message carries (HoA, BID, FID). In the message, the UE can request for moving a Service Data Flow (SDF) transmitted through the non-3GPP access (represented as the FID) to a 3GPP access network (represented as the BID) or vice versa (that is, a routing rule is changed). The UE also can request for deleting the routing rule or adding a new routing rule. If a routing rule is newly added, the message also includes Routing Filters.
In step 503, after receiving the binding update message, the P-GW/HA executes flow binding updates including flow mobility, new addition or deletion and so on according to the carried parameters such as the HoA, BID and FID. A PCEF located in the P-GW sends an Indication of IP-CAN session modification request to the PCRF, and the PCEF will send event trigger ROUTING_RULE_CHANGE and IP flow mobility routing rule information which includes installing, modifying and/or removing an IP flow mobility routing rule to the PCRF. In the routing rule, an IP Address1 is adopted to indicate that an access network performing transmission currently is of non-3GPP, and an IP Address2 is adopted to indicate that an access network performing transmission currently is of 3GPP. The Routing Filters are adopted to indicate service data flows.
In step 504, the PCRF installs, modifies and/or removes the IP flow mobility routing rule. The PCRF updates a PCC rule according to the IP flow mobility routing rule. With regard to an IP flow mobility routing rule newly installed by the PCRF, it may cause a service data flow corresponding to the IP flow mobility routing rule to move from a default route to a route designated by the IP flow mobility routing rule. With regard to an IP flow mobility routing rule changed by the PCRF, it may cause the service data flow corresponding to the IP flow mobility routing rule to move from a source routing path to a new routing path. With regard to an IP flow mobility routing rule deleted by the PCRF, it may cause the service data flow corresponding to the IP flow mobility routing rule to move from the source routing path to a path of the default routing rule.
In step 505, the P-GW/HA returns binding acknowledgement message to the UE, and the message carries the HoA, BID and FID to acknowledge that the routing rule of the UE is updated successfully.
In step 506, if a PMIPv6 tunnel is established between the S-GW and P-GW, the PCRF will install or delete a QoS rule on a BBERF in the S-GW according to the rule reported by the PCEF. If it is to move from the non-3GPP to the 3GPP, the QoS rule is installed, and conversely, the QoS rule is deleted.
In step 507, the BBERF installs or deletes the QoS rule, and the S-GW initiates and executes a 3GPP bearer establishment procedure, a 3GPP bearer modification procedure or a 3GPP bearer deletion flow to perform a resource allocation, modification or release.
In step 508, the BBERF returns acknowledgement message to the PCRF.
If a GTP tunnel is established between the S-GW and P-GW, the P-GW will initiate the 3GPP bearer establishment procedure, 3GPP bearer modification procedure or 3GPP bearer deletion flow after the step 504. The steps 506-508 will not be executed.
In step 509, the PCRF will install or delete a QoS rule on a BBERF in a trusted non-3GPP access network or ePDG according to the rule reported by the PCEF. If it is to move from the 3GPP to the non-3GPP, the QoS rule is installed, and conversely, the QoS rule is deleted.
In step 510, the BBERF installs or deletes the QoS rule, and a specific non-3GPP resource allocation procedure, a specific non-3GPP resource modification procedure or a specific non-3GPP resource release procedure is initiated and executed.
In step 511, the BBERF returns acknowledgement message to the PCRF.
It can be seen from the above flows that, when the policy and charging control of the IP flows is executed, the PCEF provides a routing rule indicating a transmission path of the service data flow to the PCRF, the PCRF determines an access network in which the service data flow is transmitted currently according to the routing rule, and allocates resources to the service data flow in the current access network. If the mobility occurs in the service data flow, the resources allocated to the service data flow are still released in a source access network.
In the related art, the IP flow mobility routing rule includes the following 4 parts:
a rule identifier: it is used for uniquely identifying a routing rule in an IP-CAN session;
a routing filter: it is used for identifying a service data flow;
a priority: it is used for identifying a priority level of the routing rule;
a routing address: it is used for identifying an access network in which the service data flow is transmitted currently, such as the IP Address1 and IP Address2 as shown in FIG. 3, FIG. 4 and FIG. 5.
The IP flow mobility routing rule includes 3 kinds of operations: installation, modification and removal. The operations of installation and modification need to carry contents of the IP flow mobility rule, need to include the rule identifier, and also need to include at least one of the routing filter, priority and routing address. During the operation of removal, it can only carry the rule identifier.
In the related art, a support is provided to the method for policy control of the IP flow mobility in a non-roaming scenario, but there is no complete solution with respect to how to support the policy control of the IP flow mobility in a roaming scenario. Especially with respect to a policy and charging control method for supporting IP flow mobility in a Visited Access (VA) (also called as Local Breakout) roaming scenario (as shown in FIG. 6), how to optimize the policy and charging control better is a problem to be solved.